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PURPOSE OF DECLARATION 

This declaration is to establish completion of the invention in the present 
application in the United States, at a date prior to Aug. 3, 2001, that is the effective date of the 
prior art US Patent Application No. 2003/0033308 to Patel et al., that was cited by the 
Examiner. 

The persons making this declaration is the inventor of U.S. Application Serial 

No. 10/001,735. 
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FACTS AND DOCUMENTARY EVTOENCE 

To establish the date of completion of the invention of this application, the 
following attached documents are submitted as evidence: 

[X] disclosure documents 

Invention disclosure document that I prepared and then filed with the 
intellectual property department of Quantum Corporation, my employer 
at the time of the invention described in U.S. Application Serial No. 
10/001,735. The invention disclosure document describes the 
invention in U.S. Application Serial No. 10/001,735. The invention 
disclosure document states the date of conception as at least as of 
January 2000. I prepared and filed the invention disclosure document 
with my then employer Quantum Corporation on May 10, 2000, as 
routine procedure for inventor employees of Quantum Corporation. 

From these documents, it can be seen that the invention in U.S. Application 
Serial No. 10/001,735 was made at least as early as January 2000, which is a 
date eariier than the effective date of US Patent Application No. 

2003/0033308, viz Aug. 3, 2001. 

2 



DodietQ01-1002-USl 



PATENT 



DILIGENCE 

Although diligence is not expressly an issue, the Applicant of the present 
application ofFerthefactof filing of U.S. Application Serial No. 10/001,735 on 
Oct. 23, 2001, as sufficient evidence of diligence in "constructive reduction to 
practice" of the invention. 

TIME OF PRESENTATION OF THE DECLARATION 

This declaration is submitted prior to final rejection, and is submitted with a response 
to a first Office Action dated Jan. 13, 2005. 

DECLARATION 

As a person signing below: 

I hereby declare that all statements made herein of my own knowledge are true 
and that all statements made on information and belief are believed to be true; 
and further that these statements were made with the knowledge that willfiil 
false statements and the like so made are punishable by fine or imprisonment, 
or both, under Section 1001 of Title 18 of the United States Code , and that 
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such willful false statements may jeopardize the validity of the application or 
any patent issued thereon. 



SIGNATURE 



Full name of sole or fttst joint inventor 

Sheng Tai Tsao 


Inventor's signature ^-y — 


Date 


Residence and Post Oflice Address ^ - 

2979 Heidi Drive, San Jose, California 95132 


Citizenship 

us 
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1.0: TITLE: rru»^ / 

Using NAS Aj^liance to Build a Non-Conventional Dis* ributed Video Server. 

2.0: Summaiy: 

While the traditional multi-processors based video serve- are poiverful but they 
are very expensive. Witii the advancement oftecfanologes in the area of netwoik 
and netwoik appliance, now it is possible to build up a n m-conventional 
distributed video server based on network appliance such as Quantum's Snap 
server, which is less expensive yet powerful to deliver thousands or millions of 
concim^nt video streams to end users. An estimated cos t per video stream can be 
delivered could be under $200 dollar. 

3.0: InvcotorBhip: 
a) Who: 

Name: Sheng (Ted) Tai Tsao 

Home Address: 2978 Tobin Drive, San Jose, CA 95 132. 

Quantum Location: Building 12 of Milpitas. 

Phone (O) 408-232-6746 (H) 408-2SI-0864 

Employee # 9342 

Dept # 52810 

E-Nfail Address: Ted.Tsao@guantum .com. WyuS3@msn.com 
DateofConoepdon: 1/2000 
Date of Reduction to Practice: 4/2000. 
4.0: The Invention: 

A) Pttrposc : 

To deliver huge number of concurrent video streams to end users at very bw cost. 

B) Background: 

a) Problems Need to be Solved: 

There are several types of video server. Some of vide o servers used multi- 
nodes SMP machine. This type of machine usually his poor perfonnance when 
number of the CPU scales up. Because cotq)les or mate of CPU may share a 
common memory, this causes the memory bus contection between different 
CPU. Some of video server use multi-node MPP mai:hine, CPU on this type of 
machine usually does not share common memory, ho ivever, they may 
commonly support a distributed file system on top of group of nodes and the 
video contents is stored on the file system. The video server on a node will be 
heavily rely on communication channel to receive rec uest from client and to 
deliver video contents stored on distributed file system to the client. Therefore, 
it requires coordination between the nodes through in Era-node commimication 
channel. Sometime the communication channel betwi«n nodes will become a 
botticneck. Besides,thesevideoserverare very expensive. The minimum per 
video stream cost is around $400 dollar. 



C) To Use NAS Appliance to Build a New Type of Distributed Video Sei ver: 



The proposed distributed video server will consist of the numbers of Snap server being 
clustered together by switches or routers. Each Snap runs independendy without 
support a distributed file system between them, hence th^re is no need to have intra- 
nodes communication between each individual Snap ser /ers. However, it requires a 
dedicated video server management station, the IP switc les or routers. By adding 
these equipment, the cost per stream will increase, however, the increased cost will be 
fractional if the large number of streams were delivered to the customer. The 
following simplified figure shows how this type of serve r can be built up to meet the 
video server requirement mentioned above. 




The basic idea behind this is that let the management station hosts the video 
server's Web site to perform the administration woric ^ and distributes a group 
of client's requests to a specific NAS server up to the maximum concurrent 
video streams that it can deliver. Actually, the manajrement station maps a 
fixed number of clients to a specific NAS server and let each server deUver the 
video streams directly to a group of clients. The ma lagement station also may 
install with a PCI video-capturing card or attached w .th external video capture 
equipment, To replicate video contents from management station to multiple 
Snap servers becomes an administration task. Let us assume that we try to 
build up an online Movie Theater with 500 seats and to see that how does this 
distributed video server will works. 

First, the Web host (management) station will accept reservation up to 500 
clients before the scheduled movie starts. It then assi gns maximum number of 
client, which corresponding to the maximum numbei of video stream a single 
Snap server can deliver, to a server. The management station also sends back 

to each client a token (a ticket) indicates which server the client has subscribed. 

When the time is up, the client should automatically start to retrieve video 
stream based on the token received. Meanwhile, a sp^ific Snap server should 
authenticate the client based on the information received from management 
station and deliver the video contents directly to the •:lient station. Further, a 



large scale of a movie theater chain can be built up ba »d on the number of 
small*$cale satellite online movie theater distributed a nong different regions. 



5.0: Related laventioo: 

6.0: Commcrcializiitioii/Pablication 
See Attached Proposal: 

7.0: Others Involved In Project: 

None 
8.0 Signatures: 

Signature: S.T.Tsao 

Date: 5/4/2000 



Use NAS Appliance to Build a Distributed Video Server 
(A Preliminary Plan) 

Ted S.T. Tsao 
Quantum Corporation 
4/10/2000 



Background Information: 



1.1:ThB Discovery of th0 Quantum Snap Property For Playing Video: 

During woiking in S3U group, I wrote a network scalable parallel stressed/load 
test for the purpose of testing a demo AVID block data :«rver on NAS of S3U. 
After transferring to Snap division, I have used the same test to run performance 
measurement testing against the Snap server. By looking at the test log, which 
resulted from the nmning multiple concurrent client test threads e^ainst a snap 
server, it is found that each client threads got almost sar le amount of data 
throughput rate, which provided by the Snap server. This means that each client 
threads can share equal amount of data bandwidth provi ded by Snap server. For 
example, if the Snap can provide 6Mbyte/sec data throughput on an 1 OOBaseT 
Ethernet interface, two client threads testing will allow tiiieads got nearly 
3 .OMbyte/sec of throughput Also, three client threads i esting will allow each 
threads got nearly 2.0Mbyte/sec while four client threac s testing will let each 
client thread got 1 .5Mbyte/sec and so on. 1 was aware of that this is a very 
important property for a video server, which needs to dc liver multiple equal rate 
of concurrent video streams out to the multiple end users such as SMbita^sec or 
6Mbits/sec per video streams. 

1.2:$126 Per Wdeo Streams Provided By Snap Sender 

The other questions came out to my niind are that if the Snap can be actually 
used for playing video, and how many concurrent videc streams a single Snap 
server can provide, what is the price for an individual v deo stream provided by 
the Snap. With these questions in mind, 1 started to usi : my spare time to 
investigate these issues with my home video equipment, First, I put MPEG 
video clip on it and play the video by using MS MediaF:layer. It works since it 
supports many different type of media file. From the N SPTL testing results, the 
average Snap 2000(133MHZ Pentium CPU/32MB memory) can provide 
5.6Mbyte/sec on a lOObaseT Ethemet interface. From here we can predict that if 
we run 3.0mbits/sec per video stream, the Snap roughly can provide 15 
concurrent video streams. If the Snap 2000 sale price i! 1 899.00, each video 
stream delivered by the Snap 2000 is $126. Due to the limited workstations 
available, three workstations are used for experimental Arorks. Let each station 
start three concurrent MediaPlayer against same video i ource on a single Snap. 
Also, let the total of nine video streams on three workst ation start to play at the 
same time so that each video streams can be retrieved £t>m same cached video 
source. The nine video streams play very stable. My i preliminary conclusion 
from this experiment is that the original prediction is basically correct and 
possibly the Snap server can be used as video server. 



f.3:r/ie Video Server on the Current Marliet: 

With explosive growth of the Internet, the mteractive ncultimedia market is 
poised for rapid growth. The media server system plays a critical role in this 



maiket such as video server. There are many types of vi ieo server on the maiket 
now such as IBM*s VideoCharge and Video Streammei on RS/6000(SMP) and 
on SP system (MPP), the nCUBE's Media Cube 30, 303, 3000(MPP, distributed 
file system solution), and the Concurrent Computer's MediaHawk Xstreams etc. 
The nCUBE's Media Cube 3000 can deliver 20000 conouncnt video streams. 
However, the price per stream is pretty high, probably ii i the range of $1000 - 
S2000 per video stream. The actual number needs to be verified.. There is no 
infoimation on video server from IBM. Most notably, the Concurrent 
Con^uter claims to provide lowest price per video stretm on ihe market by their 
MediaHawk Xstreams. The average per video stream p dee is between $7Q€ to 
$800 depends on the configuration. Their Ethemet based solution is $379 per 
streams. Therefore, compare the Sn^ server's $126 per video stream to other 
vendor's solution, the Snap server could potentially position itself to play a 
significant role in die video server market Nevexthele: s, with current 
implementation of the Snap server, it can not be truly wed as a video server since 
it lacks of a complete customer solution. However, evei with additional cost add 
up for a complete solution, the Snap Server still can provide the lowest cost for 
per streams. The following section will discuss what an: the requirements that 
will let Snap server becomes a true video server. 

2. The Requirements of a Video Server: 
2.1:The Basic Requmments: 

2.1 .1 . Provide concurrent video streams. 

As discussed in section 1.1 and 1.2, the Snap car provide IS concurrent 
video streams if IS client access the same video x)urce at the same time. 
This is good in terms of supporting business app ication such as online 
Movie Theater, or online educational training ckss etc. To support true 
video on demand (VoD), the number of the concurrent video streams a 
Snap can support will drop significantly due to tlte random access requests 
from each client. In a extreme case, it may force: : the Snap to getting data 
from disk for each client in most of time instead of get data from file 
system's buffer cache. From the NSPLT test an<l experiment, the Snap 
can provide 4 concurrent stable video streams in a situation very close to 
the extreme case. This implies that a Snap can sipport minimum 4 
different movies to 4 different clients at the samv. time. More experiments 
may be required to establish a VoD access model. However, it is possible 
to provide a new scheme to redistribute the random requests from different 
clients to different Snaps to avoid access different video contents on a 
single Snap, specially in dealing with video on d emand. I will discuss the 
solution in section 2.3. 



2.1.2. Volume capacity. 

A 1 hour 3Mbits/sec steam video movie may reqidie 1.8GB of disk space 
(3Mbits * 3600 + overhead in RAID or file system => 1.35GB + 
overhead). A 20GB Siu^ 2000 may roughly stor : 1 1 hours movie. A 
120GB Snap 4000 can store 66 hours video. Witi 6Mbits/sec video 
stream, the number of hours video movie can be stored will be reduced to 
the half of the number mentioned above. For vide o server, this is good 
enough to store 3 to 4 movies on the machine. A ndeo server may be 
connected to a video archive to access huge volume of video contents. 

2.1.3. Video contents management 

The video contents management need to include X) list the video sources 
stored on Snap, to arrange a specific video soure< : to be served for clients, 
to copy or encode the video source on Snap, or ai :cept reservation for 
client who subscribe the video etc.. 

2.1.4. Video contenta encoding. 

Hie video contents encoding could be done by ing the off the shelf 
products such as either a PCI video c^ture card >r an extemai video 
capture equipment, which installed or connected to the video server 
management station. 

2.1.5. Scalability. 

The key solution for a video server's success is i s scalability. This will 
allow the video server to support a wide range oi business firom small to 
large. In section 2.3, 1 will describe a solution to let the Sn^ server 
become a scalable distributed video server, whia i can provide almost 
uidimited video streams. 

2.1.6. Network Interfaces. 

Currently the Snap provides IP/Ethemet connect on. So the IP 
switch/router could be used to deliver the video ( ontents from Snap to the 
PC user. Also, the Ethernet to ADSL router coul 1 be used to deliver the 
video contents from Snap to the TV station with a set Top box. In the 
fiiture, it may need to investigate other network i nterface for delivering the 
video contents to the end users. 

2.1.7. Fault handling. 

It is critical for a video server to provide fault handling. A preliminary 
scheme will be discussed in the following sectio i. 



3. The Proposed Distributed Video Server: 



3,1:The Classas ofUtB Video Server: 

Theie are sevml types of video server. Some of video s srvers used mtdti-nodes SNfP 
machine. This type of machine usually has poor performance when numher of &e 
CPU scales up. Because couples or more of CPU may share a common memory, this 
causes the memory bus contention between different CP J. Some of video server use 
multi-node MPP machine, CPU on this type of machine jsually does not share 
common memory, however, they may commonly suppoit a distributed file system on 
top of group of nodes and the video contents is stored on the file system. The video 
server on a node will be heavily rely on communication :hannel to receive request 
fiom client and to deliver video contents stored on distril juted file system to the client 
Therefore, it requires coordination between the nodes tfaiough intta-node 
communication channel. Sometime the communication c hannel between nodes will 
become a bottleneck. 



3,2:The Non-Conventionai Distributed Video Server 

The proposed distributed video server will consist of the numbers of Snap server 
being clustered together by switches or routers. Each Snip runs independently without 
support a distributed file system between them, hence thire is no need to have intra- 
nodes communication between each individual Snap ser fcrs. However, it requires a 
dedicated video server management station, the IP switc hes or routers. By adding 
these equipment, the cost per stream will increase, howe /er, the increased cost will be 
firactional if the large number of streams were delivered ;o the customer. The 
following simplified figure shows how this type of server can be built up to meet the 
video server requirement mentioned above. 




The basic idea behind this is that let the management sii tion hosts the video 
server's Web site to perform the administration works aid distributes a group of 
client's requests to a specific NAS server up to the max: mum concim^nt video 



streams that it can deliver. Actually, the management sti4ion maps a fixed 
number of clients to a specific NAS server and let each ssiver deliver the video 
streams directly to a group of clients. The management station also may install 
with a PCI video-c^turing card or attached with externa I video capture 
equipment To replicate video contents from manageme it station to multiple 
Snap servers becomes an administration task. Let us ass ime that we try to build 
up an online Movie Theater with 500 seats and to see tlut how does this 
distributed video server will works. 

First, the Web host (management) station will accept res ervation up to 500 clients 
before the scheduled movie starts. It then assigns maxin .um number of client, 
which corresponding to the maximum number of video stream a single Snap 
server can deliver, to a server. The management station dso sends back to each 
client a token (a ticket) indicates which server the client las subscribed. When 
the time is up, the client should automatically start to retieve video stream based 
on the token received. Meanwdule, a specific Snap serve: should authenticate the 
client based on the information received from managemt :nt station and deliver the 
video contmts directly to the client statioa Further, a \acgt scale of a movie 
theater chain can be buih up based on the number of sm dl-scale satellite online 
movie theater distributed among different regions. 

3.1: The Support of Video on Demand: 

To support VoD for 2 to 3 different video contents should be relatively easy to 
accon^lish since a single Snap 2000 can contain as man^ as 1 Ihours 3Mbits/sec 
video contents. The video server management station cc uld assign specific client 
request for a specific video content to a group of Snap s srver while assign other 
group of client requests for other video contents to other correqxniding groups of 
Snap server 

To truly support video on demand such as support view )f a specific video from 
an arcldved video library, where thousands of video con ents are stored, a more 
complicated infrastructure are required. First, the propo ;ed video server must be 
connected to a video archive storage and be able to retric ve the desired video at 
anytime. Second, a single Snap server may bededicatiigtoservesucha 
specific requirement. An infrastructure based on access ]>attem may need to be 
investigated to meet such needs. 

3,2: The Fault Handling: 

The Snap 2000 can be configured with RAIDl while Sn ip 4000 can be 
configured with either RAIDl or RAID5. This provides data protection on the 
disk against fault of a single disk. In the case of Snap s< ^ers network fitult, a 
spare Snap must be ready to take the assigned workload off the fault Snap server. 

The management station must consistently monitor all Snap's operation. The 
ratio between the number of spare Snap and the total nuj nber of Snap need to be 
calculated. Since this is a preliminary discussion for th< : fauh handling, other 
faults is not in the scope of this discussion. 



3,3:ThB advantages: 

The advantage of this q)proach is obvious that is simple . The off the shelf Snap 
can be used directly to deliver video streams to the clie its. The only major works 
needed is for management software on management sta ion. It is scalable. To 
deliver more streams, just add more Snap servers and s> /itches/routers. The 
number of streams can be delivered is almost unlimited It is efficient. Smce each 
Sn^ server is running independently without sharing aiiything with other, there is 
no bus contention problem like multi-node SMP system has. In addition, there is 
also no communication bottleneck between nodes like >4PP system has due to no 
needs for intra-node routing and communication. The prr stream price is low if 
the large number of streams were delivered to the end u sers even at the added the 
additional cost of management station and routes/switcl les. We can deliver our 
video server bellow the $200 per video streams, which :s about half price of 
Concuiient Computer's Xstreamer and well bellow the cuirent lowest price on 
the market 

4. The Video Server Development: 

4.1: The Development Goals: 

• Phase I : Setup a development environment and dete rmine the initial 
management station's platform. 

• Phase 2: Build a proto-typed video server. 

• Phase 3 : Initial product demo. 

• Phase 3 : Build a commercial video server and beta 1 esting. 

• Phase 4: Go to the market 

• Phase S: More development. 

4.2: The Resource Requirement: 

a) Engineer requirement: 

Besides myself, initially two additional software eni^ineers are required. More 
persons are required at different stages of product d :velopment. 

b) Equipment Requirement 

I have inherited some equipment from former S3U :sroup. However, this is not 
enough. Some additional woricstations, video capture equipment, and others 
may be required. 

4.3:The Dependencies: 

Initially this video server relies on Sn^ server product therefore, the support 
from Snap server division is required. 

4.4: The Schedulm: 

a) Phase 1: 3 months. 

b) Phase 2 and phase 3: 6 months. 

c) Phase 4: 4 months. 



d) Other phases: TBD. 



5. The Business partner: 

At the various product development stages, we may establish our business partner 
with various vendors to expand our product lines and to expand our market 
presence. 



6. The Conclusion: 

With the rapid growth of Internet, the needs for deliver muliimedia on the Internet are 
growing. While the traditional video (multimedia) servers jre powerful but they are 
very expansive. With the advancement of technologies in die area of network and 
network appliance, now it is possible to build up a non-con /entional distributed 
video server based on network appliance such as Quantum' Snap server, which is 
this also will allow us to buUd up a new computation model for a new type of server 
which is different from the traditional server based on SMP or MPP architecture. 
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